hack console

Suite de mes aventures. Retour à un OFW 4.88, formatage hdd interne bloquait, donc passage par le PC, remise du HDD avec réinstall automatique qui a finalement fonctionné. La console affiche toujours des sauts d image, un peu psychédéliques. Et je constate que quand je la branche en sortie composite, ou en HDMI, elle affiche parfois l image, parfois pas (en particulier après un temps débranché de plusieurs heures). Et malgré l appui long pour réinitialiser le paramétrage de sortie vidéo, il faut parfois 5 reboot pour que l affichage revienne, il n y a que le son ou même parfois des freeze bloquants, parfois obligé de couper au bouton directement car tout est bloqué. A chaud ou à froid c est aléatoire comme depuis le début.
Donc je penche pour un problème matériel, j ai peut être fait une fausse manip ou endommagé au démontage (électricité statique ?)...
Ou alors c est une coïncidence et comme elle n avait pas tourné depuis longtemps le fait de la remettre en route + soufflette + le hack l ont achevé...

Comme indiquait dans mon explication dans ton autre demande, cela ne sera pas sans risque pour la console hackée. En espérant que non.

Et dans son cas, il utilise SX OS donc cela va être difficile de mettre à jour dans une même version sauf s’il a créé une emuNAND et dans ce cas, seule la sysNAND pourra l’être mais il grillera les eFuses LOTUS du port cartouche.

Merci pour ton retour.

Ce n’est pas trop le sujet du tutoriel et aucune raison que cela apparaisse en FAQ. Un sujet dans une autre section aurait dû être privilégié.

Cette demande a déjà été demandée d’ailleurs.
https://gamergen.com/forums/blabla-swit ... 67654.html

Il me semble que cela s’opère de manière simple d’une Switch à l’autre lorsqu’il s’agit de la sysNAND (NAND système de la console) et ce sans réel besoin que les deux soient hack ou non sauf erreur. Et cela sans compter le fait que certains jeux passent par un outil tiers (ex: Animal Crossing New Horizon) ou d’autres qui utilisent le Cloud. Dans ces deux derniers cas, cela ne passe pas par l’outil de transfert de la console.

En revanche, transférer une sauvegarde sur l’emuNAND depuis une console jailbreak sur une console non hack, ne pourra pas passer par l’utilitaire simple de la console. Il faut dans ce cas utiliser un outil tiers ou une méthode tierce qui nécessite que les deux soient jailbreak. Comme indiquait dans le sujet en lien, je n’affirme rien en disant cela car non testé mais cela me semble logique.

SysNAND et emuNAND sont déliées donc l’une ne communique pas avec l’autre. Et il existe toujours l’idée du dump via un outil tiers pour ensuite les restaurer mais comme dit, cela implique un jailbreak sur les deux consoles.

Les méthodes qui passent par le online depuis le CFW emuNAND provoquera un bannissement de la console. Et quand il s’agit de la sysNAND, il faut être certain que celle de la console hack soit vraiment clean. Les outils tiers comme JKSV, DBI ou autres permettent de dumper les sauvegardes de l’emuNAND vers la sysNAND pour ensuite faire un transfert de données simple sur sysNAND mais cela présente un risque également.

Après il existe la méthode tierce qui passe par memloader/HacDiskMount/Hactoolnet mais il faudra faire des recherches car ceci est assez complexe.

La puce est un moyen préalable pour ensuite utiliser un hack sur une console patchée. Ne pas tout mélanger mais ce moyen va à l’encontre de Nintendo tout de même.

La nuance concerne également le software utilisé ensuite. Si on se base sur la Team Xecuter et leur CFW SX OS, il bafouait le droit de Nintendo (et d’autres développeurs) car il utilisait du code propriétaire et se rajoutait à cela la vente d’une licence donc profit derrière (entre autres choses). Pour ce qui concerne Atmosphère/Hekate, ce n’est pas le cas.

Dans le cas d’une utilisation du CFW Atmosphère, il faut notamment les sigpatches pour les jeux dits non legits et le dump des keys pour utiliser certains outils, ce qui ne respecte pas non plus les droits de Nintendo. Mais cela n’est pas mis à disposition par les développeurs SciresM (AMS) et CTCaer (Hekate). Ainsi, ils ne sont pas inquiétés par Nintendo.

Pour ce que tu demandes, cela nécessitera des outils tiers mais rien à voir avec la puce puisque c’est un moyen hardware pour flasher et utiliser un hack. Le reste passera par des outils comme dit juste avant.

Le mieux serait de lire les différents sujets sur la Toile car là je résume grossièrement. Et aucun support ne sera donné sur le forum en rapport avec ses puces donc pour approfondir le sujet, tu peux consulter le site GBATemp ou autre.

Merci pour la réponse.

Je vais me chercher un dongle pour booter avec un JIG.
Pour l’histoire du trombone, il suffit de vérifier sa position, le jig fait exactement la même chose, il suffit de ne pas faire ça comme un sauvage.
La console est éteinte quand elle ne sert pas. D’où la nécessité d’avoir la possibilité d’injecter les paquets en quasi-autonomie.

En ce qui concerne les jeux à jour et leurs messages, ça concerne des jeux dématérialisés en ce qui me concerne. Donc je vais laisser tel quel.

D’ailleurs aucun risque de ban lorsque je joue après un reboot sans avoir le hack actif et en laissant les DNS auto, c’est bien ça ?
Le seul truc c’est que ça me proposera d’installer la MàJ et ça au pire ça se saute.

Merci beaucoup pour ta réponse.

Je demande pas de lien juste savoir si je pouvais cracker ma console. Est ce que sa vaut le coup de le faire par puce sachant que ceux qui en font ont était attaquer en justice et il y a des risque de ban online ?

Si si, justement je ne suis pas contre mettre à jour la console. Juste peur de perdre toute la partie hack, notamment les applications.
Toujours un mal de fou à refaire tout fonctionner.

Il faut désactiver le mode autoRCM et ensuite procéder comme indiqué.

En revanche, pourquoi ne pas mettre à jour si tu utilises le hack Atmosphère/Hekate. La seule raison de ne pas le faire, c’est soit que tu as une console concernée par la méthode Pegascape ou alors, tu utilises SX OS.